When you create or change an existing CM website, navigation item, content folder, content record, or any other CM definition object in the Document System and click Save, nothing happens except that iMIS stores a Working version of that object in the iMIS database. It is only when you click Publish that iMIS actually implements the new version of the definition object, replacing the previous Published version of the object with this new Working version and then marking it with a status of Published to indicate that it is now the current active version.
When you publish the various types of CM definition objects, different things happen depending on what type of object it is:
Note: The following descriptions generally apply to the publishing option Publish Working Items Only. If you select either of the other publishing options, then objects in any state are published.
■ Websites - No downstream processes happen other than CM creates a corresponding sitemap if it is an entirely new website, so that you have a structure into which you can add navigation items. If you have developed your own custom master pages and themes, the people in your organization who perform website administration should have already placed the necessary files on the servers that will host the website.
■ Navigation items - When a browser first requests a website URL from the iMIS application server or an external web server that has been prepared to host CM websites, the CM code on that server examines the Published sitemap object in the iMIS database and then builds a corresponding in-memory representation of the sitemap's navigation structure. A timer process then re-checks the iMIS database every 5 minutes (by default) to determine whether a newer version of the sitemap object has been published, and, if so, the CM code on that server rebuilds its in-memory sitemap structure for that website.
Note: You can change this default 5-minute polling interval if desired, but be aware that each polling process consumes a small amount of system resources so there is a performance tradeoff in specifying a more frequent polling interval. To change the polling interval, edit the value of the Sitemap.CachePeriod key (expressed in minutes) in the <SystemParams> declaration in the web.config file for the iMIS application (IIS application \iMIS).
■ Content folders - No downstream processes happen other than iMIS checks the status of all descendant content records and sub folders and if it finds any that are currently in a Working state, it automatically publishes them too. This enables you to spend several days working on a major change to your website content that encompasses many content records, and then publish all those changes in one action by publishing a content folder high enough in the folder hierarchy to cover all the content records that are in a Working state.
Changes made to the Access Settings of a content folder that are applied to all descendants are saved to the Published descendant content records without the need to re-publish each record. Security checks to determine whether the rendered version of a content record should be served to the requesting browser are performed by examining the current Access Setting values of the Published content record object in the iMIS database.
■ Content records - iMIS checks the value of the Publish on Servers field in the parent content folder to determine which publishing servers should handle the publishing of the content record. iMIS then creates a separate publishing request in the iMIS database for each associated publishing server. Meanwhile, every 5 minutes (by default), the publishing services (AsiPublishing15) installed on every server that hosts CM websites are polling the iMIS database to determine whether there are any new publishing requests designated for their corresponding publishing server.
If so, the publishing service examines the Published content record object in the iMIS database and then renders a corresponding .aspx file and places that file in the appropriate location in the server's local file system so that IIS can serve that page to browsers that request the content record's corresponding navigation item link.
Note: You can change this default 5-minute polling interval if desired, but be aware that each polling process consumes a small amount of system resources so there is a performance tradeoff in specifying a more frequent polling interval. To change the polling interval, edit the definition for the corresponding publishing server and specify the desired polling interval in the Frequency field.
Note: The CM configuration field CM.PublishingMaxNumOfAttempts (located in System Setup > Set up content management > Content designer configuration) determines how many times each publishing service will attempt to process a system publishing request before it flags the request as failed. This prevents overconsumption of system resources if there is a connection issue or other issue that is preventing the publishing service from successfully processing the request.
■ Content layouts - No downstream processes happen. When you define a content record, iMIS populates the list of available Page Layouts by examining all the Published versions of content layout objects in the iMIS database.
■ Content types - No downstream processes happen. When you define a content record, iMIS examines the Published content type objects in the iMIS database to determine how to display the corresponding iPart when added to the content record.
■ Tagged list formats- No downstream processes happen. When you add a ContentTaggedList iPart to a content record, iMIS populates the list of available List Formats by examining all the Published tagged list format objects in the iMIS database.